就如同我們上篇說到，一家餐廳的成功運營，仰賴於廚師、服務生、經理等不同職位的各司其職。同樣地，在軟體開發的龐大工程中，若要開設一家名為「專案」的餐廳，也需要一位如同餐廳總管的角色（通常是產品經理或架構師），將所有人的職位、技術與職責，轉化為一份大家都能看懂的藍圖。

而 UML（統一建模語言）正是這樣一套標準化的「畫法」，它提供了多種圖表，讓我們能將複雜的系統框架（Framework）與流程（Flow）具象化。無論是描繪系統結構，還是呈現使用者操作流程，UML 幾乎都能融合需求，提供對應的視覺化方案。

然而，它的缺點也同樣顯著。繪製精美的 UML 圖極度耗時，更麻煩的是，在實際開發過程中，需求變更與技術調整是家常便飯，這意味著 UML 圖也需要頻繁地修改，有時甚至與最終成品脫節。

甚至在軟體行業，會UML手藝的人已經越來越少
可以看下方推薦的博主【原子能】，他講述了UML的一些歷史，包含如何UML坑死程序員等等

UML 沒落的原因主要有三點：
1.跟不上複雜度的腳步：當系統邏輯變得極度複雜時，UML 圖（如狀態機圖）會變得臃腫不堪，難以呈現所有細節，資訊的丟失使其失去了參考價值。

2.敏捷開發的興起：RUP 所代表的瀑布式開發模式，逐漸被快速迭代、靈活應變的敏捷開發所取代。在追求速度與彈性的前提下，耗費大量時間維護詳盡的 UML 文件，顯得不合時宜。

撇開這些不說，UML 在我與客戶的溝通上，其實仍扮演著不可或缺的角色。當我需要向客戶闡述一個新 App 的初步構想、解釋其核心邏輯與可能的系統架構時，一張簡潔的 UML 圖，遠比上千字的文字描述來得更清晰有力。

這也體現了它最大的功能：讓客戶看得懂，並讓自己的設計有一套統一化的規範。

不過，這裡有個關鍵訣竅：我們應該將 UML 圖定位在「大概位置」，而非「精確座標」。在專案初期，我們繪製的應該是高層次的架構圖與流程圖，捕捉核心精神，而非鑽牛角尖於每一個細節的實現。這樣做的好處是，當後續需要變動時，我們能保留更大的修改空間，避免被自己親手繪製的藍圖所束縛。

總結來說，UML 或許不再是軟體開發的命脈，但它所代表的「視覺化溝通」與「標準化建模」思想，依然是每一位產品經理與架構師的核心概念。學會善用其長處，將其作為溝通的橋樑，而非開發的枷鎖，所以依然能在我的工具箱中佔有一席之地。

下一篇就來介紹一個如何繪畫一個簡單的UML